Форма входа
0/0
Настольная книга тимлида разработки ПО - Виктор Большаков
- Дата:29.07.2024
- Категория: Компьютеры и Интернет / Программирование
- Название: Настольная книга тимлида разработки ПО
- Автор: Виктор Большаков
- Просмотров:3
- Комментариев:0
Уважаемые читатели!
Тут можно читать бесплатно Настольная книга тимлида разработки ПО - Виктор Большаков. Жанр: Программирование. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Настольная книга тимлида разработки ПО - Виктор Большаков:
Книга родилась из курса внутреннего обучения роли Тимлид в DatsTeam. Тем не менее её ценность для всего сообщества тимлидов заключается в обобщении необходимых компетенций. Этот набор компетенций формирует общий стандарт в отрасли разработки ПО.
Программирование
Аудиокнига "Настольная книга тимлида разработки ПО" от Виктора Большакова
📚 "Настольная книга тимлида разработки ПО" - это увлекательное путешествие в мир управления разработкой программного обеспечения. Вас ждет множество полезных советов, инсайтов и стратегий, которые помогут вам стать успешным лидером в IT-индустрии.
Главный герой книги - тимлид, который сталкивается с различными вызовами и проблемами в процессе работы с командой разработчиков. Он учится принимать решения, мотивировать коллег и эффективно управлять проектами, чтобы достичь поставленных целей.
Автор книги, Виктор Большаков, является опытным специалистом в области разработки ПО и управления проектами. Он делится своими знаниями и опытом, помогая читателям развить лидерские качества и стать успешными профессионалами в IT-сфере.
На сайте knigi-online.info вы можете бесплатно и без регистрации слушать аудиокниги онлайн на русском языке. Здесь собраны лучшие бестселлеры различных жанров, включая книги по программированию.
Не упустите возможность улучшить свои навыки управления проектами и стать успешным лидером в области разработки ПО с помощью аудиокниги "Настольная книга тимлида разработки ПО" от Виктора Большакова!
Погрузитесь в увлекательный мир IT-индустрии и станьте лучшей версией себя уже сегодня!
Программирование
Читем онлайн Настольная книга тимлида разработки ПО - Виктор Большаков
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
до сути, вы можете потратить силы на лечение симптомов, а не первопричин.
Как реагировать?
Есть 3 варианта реакции на выявленные проблемы:
— Коммуникация с другими подразделениями и внешними контрагентами
— Исправление процесса с владельцем процесса
— Управленческое воздействие на сотрудников
Большая часть бизнес-процессов на предприятии не изолирована, а связана с работой других подразделений. Даже, например, вход в ваш процесс обеспечивает какой-то другой. Если итоговые результаты вашей работы неудовлетворительны из-за ошибок, в поступивших к вам на начальном этапе входных данных — это повод обсудить ситуацию с руководителем другого подразделения. Поиск компромисса необходим для предотвращения дисбаланса, когда сверхэффективность одних подразделений может оборачиваться худшей результативностью других. Также ваш процесс может зависеть от работы подрядчиков, что не может снимает с вас ответственности как с менеджера процесса.
Результат вашего процесса зависит не только от внешних коммуникаций. Если результат не соответствует ожиданиям, возможно, сам процесс спроектирован неверным образом. Потребители могут жаловаться на качество, скорость или стоимость процесса. Вам как менеджеру, нужно понять, какие рекомендации владельцу процесса дадут наилучший результат. Например, входящий в разработку поток заявок от бизнеса принято классифицировать на: Инциденты. Новый функционал и другие категории. Это необходимо, чтобы наилучшим способом (баланс качества, скорости и стоимости) решить каждую из заявок. Каждый этап процесса уникален и требует переосмысления, ведь он может иметь отклонения от общих правил, адаптируясь под разные ситуации. Причины неудовлетворительного результата — описание процесса может быть либо недостаточно детализированным, либо наоборот слишком конкретным, что не дает сотрудником подходить к решению задач творчески.
Наконец, ваши сотрудники могут не соблюдать предписанный процесс (умышленно или неосознанно). Сами управленческие воздействия мы разбирали выше в блоке «Мотивации членов команды».
Одной из классических функций менеджера является Планирование. Для оптимизации собственных ресурсов остальным подразделениям важно понимать, когда вы сделаете ту или иную задачу.
Прогноз результатов строится из выходных результатов процесса, понимания доступных ресурсов на прогнозируемый период и из потенциальных изменений или рисков.
Проблема с метриками заключается в том, что сотрудники в погоне за видимостью результата могут предоставить вам лишь красивые цифры. Так часто происходит, когда бонусы привязываются к KPI. Не попадайте в эту ловушку, лучше, чтобы сотрудники не знали о том, какие вы хотите увидеть цифры и по каким метрикам.
Аналитика
Вход процесса: Заинтересованные лица, требования к системам
Цели процесса:
— Оценка объема аналитики по задачам
— Скорректированные ожидания заказчиков
— Согласованное описание требований заказчиков
— Обновленная документация продукта
— Обученные сотрудники, проведенное демо и др.
Метрики:
— Удовлетворенность работой аналитика (Заказчик/Архитектор/Разработчик/…)
— Количество задач с описанными требованиями
Программирование
Вход процесса: Согласованные требования по задаче
Цели процесса:
— Оценка сложности и времени выполнения задач
— Написание кода, реализующего рабочие требования
— Проверка соответствия кода соглашениям/стандартам
Метрики:
— Соответствие времени решения задачи плановым показателям
— % прохождения статического анализа кода
— % прохождения автоматизированного тестирования
— % прохождения ручного тестирования
— Количество выполненных задач
— Объем выполненных задач
Контроль качества
Вход процесса: Выполненная задача
Цели процесса:
— Оценка сложности и времени тестирования задач
— Соответствие нового функционала заданным требованиям и ожиданиям заказчика
— Отсутствие дефектов в связи с внедрением нового функционала
Метрики:
— Оценка сложности и времени тестирования задач
— Среднее время ожидания тестирования
— Скорость тестирования задач
— % пропущенных ошибок
— % автоматизированных тест-кейсов
Качество можно рассматривать шире, например в рамках теории Total Quality Management.
Публикация новых версий
Вход процесса: Готовая к публикации новая версия
Цели процесса:
— Опубликованная новая версия
— Минимальный ущерб в связи с публикацией новой версии (простой, ошибки)
— Минимальная стоимость процесса сборки и публикации
Метрики:
— Среднее время ожидания публикации задачи после успешного тестирования
— Сумма простоя в процессе публикации
— Количество инцидентов во время публикации
— Количество публикаций в целом
Обслуживание и поддержка
Вход процесса: Система, с которой работают пользователи
Цели процесса:
— Минимизация времени обслуживания заявок пользователей
— Минимизация отказов и времени даунтайма системы
— Минимизация стоимости процесса
Метрики:
— Метрики SLA
— Uptime
— Количество специалистов, необходимых для поддержки функционирования систем
Используйте post-mortem отчеты для анализа инцидентов доступности продукта. Они помогут команде исправить причины, которые привели к инциденту или деградации.
Прием, распределение и контроль задач в подразделении
Качество постановки задач
Какие задачи у вашей команды, кто их и как ставит? Ощущение вас как руководителя складывается в первую очередь из поставленных задач и того, как вы их принимаете. Все это делают по-разному. Одним достаточно контролировать техническую часть, поручая контроль закрытия другим сотрудникам. Другие же ограничиваются только распределением задач. На самом деле вы должны отстаивать интересы заказчика внутри вашей команды, а значит ставить задачи и контролировать процесс их выполнения в полной мере.
Многие начинающие руководители недооценивают необходимость грамотной постановки задач, хотя это напрямую влияет на качество их выполнения. По этой причине в современных методологиях вышеупомянутой проблеме уделяется больше внимание. Мы будем рассматривать постановку задач в процессе разработки ПО.
Методики постановки задач:
— S.M.A.R.T. является аббревиатурой, где каждая буква означает критерий эффективности поставленных целей или задач.
— Specific — (конкретный) — нацельте на конкретную область для улучшения
— Measurable — (измеримый) — дайте количественную оценку или предложите показатель прогресса
— Assignable/Attainable — (назначаемый/достижимый) — укажите конкретного исполнителя
— Realistic — (реалистичный) — опишите, какие результаты могут быть реально достигнуты при наличии ресурсов
— Time related/Tangible — (связанный со временем/осязаемый) — укажите, когда может или должен быть достигнут результат
— User story (пользовательские истории). Если говорить про Agile разработку, то пользовательские истории рекомендованы как наиболее простой и понятный заказчику способ. Но вместе с простотой появляются проблемы с невыявленными требованиями. Предложено несколько формул пользовательских историй:
— Я как <Роль> могу <Функционал>, чтобы <Получить ценность>
— Для того чтобы мне <Получить ценность> как <Роль>, я могу <цель/возможность>
— Как <Кто> <Когда> <Где> я <Хочу>, потому что <Причина>
— К пользовательским историям и не только часто применяется I.N.V.E.S.T. метод
— Independent (независимость) — Старайтесь избегать создания задач, которые зависят друг от друга
— Negotiable (обсуждаемость) — задачи не являются формальным контрактным обязательством или требованиями
— Valuable — ценность для пользователя и покупателя
— Estimable (оцениваемость) — разработчики должны иметь возможность оценить размер задачи
— Small (компактность) — от размера задачи зависит очень многое, слишком большие и слишком маленькие задачи сложно оценивать
— Testable (тестируемость) — подтверждением того, что задача разработана успешно, служит удачное прохождение тестов
— DoD (Definition of Done) — критерий готовности, некий формальный набор работ/мероприятий, свидетельствующий о законченности задачи. В этот список могут попасть автотесты, документация и проведено ревью. Набор необходимых условий для решения задачи.
— Acceptance Criteria — критерии приемки,
На этой странице вы можете бесплатно читать книгу Настольная книга тимлида разработки ПО - Виктор Большаков бесплатно.
Похожие на Настольная книга тимлида разработки ПО - Виктор Большаков книги
- Настольная книга по домоводству. 1000 практических советов на все случаи жизни - С. Потапкин - Прочее домоводство
- Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова - Программирование
- Формирование технологии разработки и принятия предпринимательских решений - Д. Кенина - Управление, подбор персонала
- Исправление прошлого и исцеление будущего с помощью практики восстановления души - Альберто Виллолдо - Эзотерика
- Личное мнение - Павел Бессонов - Поэзия
